Method and apparatus for forward error correction in packet networks

ABSTRACT

A method for applying forward error correction in a transmission network includes the steps of choosing one of a plurality of possible error correction codes, using an appropriate field to encode a complete forward-error-correcting (FEC) code algorithm in each FEC packet to be transmitted. The packet stream, consisting of media packets and FEC packets can be sent to both FEC-capable and FEC-incapable receivers. Decoding methods are independent of the forward-error-correcting code transmitted. The sender can adapt the forward-error-correction code algorithm and the degree of error correction provided on a one-time basis or even more dynamically. Decoding and recovery at the receiver require no prior notification from the sender. Applying the FEC code algorithm to decode includes interrogating the bits in an offset bit mask in each FEC packet to yield links with media packets, and applying other fields of the FEC header to obtain instructions to recover lost data in one of the media packets. Based thereon, reiterative decoding of media packets ensures that lost data recoverable with combinations of media packets and FEC packets are recovered.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application Ser.No. 60/077,991, filed Mar. 13, 1998.

FIELD OF THE INVENTION

This invention relates to correction of errors, such as packet loss, intransmission networks of the packet network type and, particularly, tomethods and apparatus for forward correction of errors in connectionlessnetworks.

BACKGROUND OF THE INVENTION

Connectionless networks, such as the Internet, often suffer from largeamounts of packet loss. Such loss is extremely troublesome for real timeapplications, such as voice and video, especially on wide-areatransmissions. These applications are delay sensitive, and therefore cannot afford to retransmit lost data. Furthermore, loss conditions on theconnectionless network may vary, even during the duration of a singlesession. To compensate for these conditions, traditional forward errorcorrecting codes (FEC) have been proposed for use on packet networks,including the Internet. Typically, these codes are statically determinedand signaled out of band, so that the code in use cannot be changedeasily during the duration of one transmission from a user. Furthermore,when the media in use are of the multicast or broadcast types,out-of-band signaling is often not possible and the FEC code is notchanged. The use of a static FEC code provides too much transmittederror-correcting code when loss rates are low and thus wastes bandwidthand provides too little transmitted error-correcting code and resultingpoor reception quality when loss rates are high.

Nevertheless, conventional practice is to use a single FEC code,signaled once, out of band. Recently, in-band signaling in a moredynamic application has been proposed for multicast. The changing ofcodes would, however, be quite restricted to a small set ofpredetermined codes. A further drawback is that all recipients would berequired to understand FEC encoding and its algorithm. In multicastgroups, this is an unreasonable expectation. Thus, more versatile andeffective error correction is needed for transmission networks andespecially for connectionless network applications.

SUMMARY OF THE INVENTION

According to a first aspect of the invention, a method for applyingforward error correction in a transmission network includes the steps ofchoosing one of a plurality of possible error correction codes, using anappropriate field to encode a complete forward-error-correcting (FEC)code algorithm in each FEC packet to be transmitted. Advantageously, thepacket stream, consisting of media packets and FEC packets can be sentto both FEC-capable and FEC-incapable receivers. In a specificimplementation of the method of the invention, a decoding method isemployed that is independent of the forward-error-correcting codetransmitted.

According to a second aspect of the invention, apparatus for applyingforward error correction in a transmission network implements themethod.

BRIEF DESCRIPTION OF THE DRAWING

Further features and advantages according to both aspects of theinvention will become apparent from the following detailed description,taken together with the drawing, in which:

FIG. 1 is a flow chart of a preferred implementation of the method ofthe invention; and

FIG. 2 shows a block-diagrammatic illustration of a preferredimplementation of apparatus using the invention.

DETAILED DESCRIPTION

The aim of the method of the invention, to be described primarily withreference to FIG. 1, is to generalize the format for forward errorprotection so that the sender can adapt the forward-error-correctioncode algorithm and the degree of error correction provided on a one-timebasis or even more dynamically. Moreover, while media packet streams andFEC code packet streams are effectively juxtaposed, no particular degreeof interleaving is required. The degree of overhead imposed is variable,dependent upon the degree of error-correction currently being provided.Capability exchanges are avoided, simplifying the protocol andeliminating compatibility problems.

Before the protocol is described, the following terms are described forclarity. A media payload is a piece of raw, unprotected user data. Amedia header is the real-time transmission protocol (RTP) header for themedia payload. The combination of a media payload and the media headeris called a media packet. The forward-error-correction algorithms at thetransmitter take the media packets as an input. They output both themedia packets as they are passed and new packets called FEC packets. TheFEC packet contains an FEC header and FEC payload. Each FEC packet issaid to be associated with one or more media packets when those mediapackets are used to generate the FEC packet. The preferredimplementation of the invention uses the Exclusive OR (hereinafter, xor)operation to generate the FEC packets.

In the preferred implementation, the FEC packets are sent as a separatestream from the media packets. By this, we mean that the FEC packetshave their own sequence-number-and-timestamp space. This mode isillustratively implemented in a manner that allows the two packetstreams to be sent by separate multicast groups. Advantageously,receivers that are not FEC-capable can easily ignore the FEC packets andjust receive the original media packets. Sequence numbers and timestampsare then coherent for each packet stream.

More broadly, however, the separate stream concept is adaptable to beingdefined by a particular application and high-level protocol. Formulticast, the separate streams may be implemented by separate multicastgroups, by different ports in the same group, or by a differentSynchronization Source (SSRC) value within the same group or port. Forunicast, different ports or different SSRC may be used. Each of theseseveral implementations will have both advantages and, possibly,drawbacks dependent on the application. At the receiver, arriving FECand media packets are used to generate a stream of media packets fordirect use by the application. Error protection is cleanly separatedfrom the application.

The protocol operates by encompassing error protection algorithms thatwork by applying some function f to one or more media payloads, whichare specified as the arguments to f. The result of applying thisfunction is an FEC payload. When the function is applied to just asingle media payload, the result is that media payload. Thus, f(a)=a. Incontrast, when the function is applied to multiple media payloads, theresult is some combination of those payloads. Preferably, f can combineany number of payloads, each with arbitrary lengths. Recovery ispossible if a sufficient number of FEC and media packets are received.Sufficiency depends on the reception of N packets (media or FEC) thatcontain linearly independent combinations of at most N media packets. Inthe preferred implementation the function f is the Exclusive OR (xor),defined as:

    f(a,b,c)=a xor b xor c.

For example, consider further the use of the xor. Media packets w,x,y,and z, with media payloads a, b, c, and d are to be transmitted. Pairsof media payloads will be xor'ed together to generate the FEC payloads.The resulting network packet stream is denoted as:

    a, b, f (a,b), c, d, f (c,d).

In this example, the error correction scheme introduces a 50% overhead.But if b is lost a and f (a,b) can be used to recover b. The ways inwhich the various implementations would differ will appear in the set ofmedia payloads over which the xor (or, more generally, f) is applied,and the order in which the resulting packets are sent.

In any forward-error-correcting code arrangement, as well as those ofthe present invention, it is necessary for the receiver to know thefunction being applied and to know the set of media payloads to whichthe function is to be applied. At the receiver, only the FEC packetsconvey the function f, according to the present invention.Specifically, the payload type in the FEC packet header is set to givethe function f.

To determine which packets are associated with an FEC packet, accordingto the present invention, a field called the offset mask is present inthe FEC packet header. Assume this mask is M bits. If bit k in the maskis set to 1, then the media packet with sequence number N+k isassociated with this FEC packet, where N is the sequence number base inthe FEC packet header. This effectively allows an FEC packet to beassociated with any of the M packets before or after it. The offset maskand the FEC payload type provide sufficient indicators for arbitrarilylarge or complex forward-error-correcting code algorithms.

When a packet is to be transmitted that contains FEC data, i.e., itspayload is derived from one or more media payloads, the RTP header isfollowed by an FEC header. In the RTP header fields, the version fieldis set to 2. The padding bit is computed via the protection operation,defined below. The extension bit is also computed via the protectionoperation. The Synchronization Source (SSRC) value should generally bethe same as SSRC value of the media stream it protects. Each SSRC valueis an identifier chosen by each respective RTP session participant. TheSSRC value of the FEC packet may be different from that of the mediastream if the FEC stream is being multiplexed via the SSRC value. Thenumber of users in a Contributing (CSRC) List of SSRC values is computedvia the protection operation. That number of users is called the CSRCcount field (CC). The CSRC list itself is never present, independent ofthe value of the CC field. The extension is never present, independentof the value of the X bit. The marked bit is computed via the protectionoperation. The sequence number has the standard definition. It is onehigher than the sequence number in the previously transmitted FECpacket.

The timestamp is set to the value of the media (RTP) clock at the timeof generation of the FEC packet. This setting allows the timestamps ofsequential FEC packets to usually increment, although timestamp behaviorfor different FEC schemes will vary. The payload type for the FEC packetis set as described above. End systems that cannot recognize a payloadtype must discard the FEC packet in any case. This fact and the factthat no media packets are discarded provide compatibility with oldersystems. The FEC mechanisms according to the invention can be used in amulticast system with mixed FEC-capable and FEC-incapable receivers.Following the RTP header is the FEC header. This header is nominally 64bits, and may optionally be extended to 96 bits, The format of theheader is as follows: ##STR1##

The length recovery field is used to determine the length of anyrecovered packets. It is computed via the protection operation appliedto the 16 bit natural binary representation of the lengths in bytes ofthe media payload, CSRC list, and extension and packing of media packetsassociated with this FEC packet. In other words, the CSRC list,extension, and padding, if present, are counted as part of the payload.This arrangement allows the FEC procedure to be applied even when thelengths of the media packets are not identical. For example, assume anFEC packet is being generated by xor'ing two media packets together. If,for example, the lengths of the two media packets are 3(0b011) and5(0b101) bytes, respectively, the length recovery field is then encodedas 0b011 xor 0b0101=0b110.

The E bit indicates a header extension. When set to 1, it indicates thatan additional 32 bits of header follow.

The PT recovery field is obtained via the protection operation appliedto the payload types of the media packets associated with the FECpacket.

The mask field is either 16 bits or 48 bits, depending on the value ofE. If the bit k in the mask is set to 1, then the media packet withsequence number N+k is associated with this FEC packet, where N is theSN Base field in the FEC packet header. The SN base field is always setto the minimum sequence number of those media packets protected by FEC.This setting allows for the FEC operation to extend over any string ofat most 16 packets, whose range in sequence numbers is no more than 16.

The TS recovery field is computed via the protection operation appliedto the least significant 8 bits of the timestamps of the media packetsassociated with this FEC packet. In this way, the high-frequencycomponent of the timestamp is recovered via FEC, while the low-frequencycomponent can be determined by interpolation.

The payload of the FEC packet is the protection operation applied to theto the CSRC list plus payloads of the media packets associated with theFEC packet.

The protection operation involves taking a variety of fields from thevarious headers, adding the payloads, appending the whole thingtogether, padding zeroes, and then computing the f operator across thewhole binary array. The result is then placed into the FEC packet fortransmission.

For each media packet to be protected, a binary array is generated byappending the following fields together:

1. Padding bit (1 bit)

2. Extension bit (1 bit)

3. CC bits (3 bits)

4. Marker bit (1 bit)

5. Payload type (7 bits)

6. Least significant 8 bits of Timestamp (8 bits)

7. Natural binary representation of the length of the CSRC List pluspadding plus payload plus extension of the media packet (16 bits)

8. CSRC List (if CC is 1), else null (variable)

9. Header extension, if X is 1, else null

10. The payload (variable)

11. Padding, if present (variable)--if the lengths of the binary arraysare not equal, arrays padded with zeroes to be the length of the longestbinary array

The preceding steps describe the generation of one binary array.

The f operator is then applied across the binary arrays. The result isthe binary array of the FEC packet. The first bit in the FEC packetbinary array is written into the Padding Bit of the FEC packet. Thesecond bit in the FEC packet binary array is written into the ExtensionBit of the FEC packet. The next three bits of the FEC packet binaryarray are written into the CC field of the FEC packet. The next bit ofthe FEC packet binary array is written into the marker bit of the FECpacket. The next seven bits of the FEC packet binary array are writteninto the PT recovery filed in the FEC packet header. The next eight bitsof the FEC packet binary array are written into the TS recovery field inthe packet header. The next 16 bits are written into the Length Recoveryfield in the FEC packet header. The remaining bits are set to be thepayload of the FEC packet. Each such FEC packet is then transmitted inthe connectionless network such as the Internet or other packet network.

Reception and decoding at the receiver are described in the following.The FEC packets allow end systems to recover from the loss of mediapackets. All of the header fields of the missing packets, including CSRClists, extensions, padding bits, and marker and payload types, arerecoverable.

The reception process will be described with reference to FIG. 1. Thesteps of FIG. 1 are executed by one or more central processing units ina receiver equipped to use the invention.

In step S11 a packet is received at the receiver. In step S13, thereceived packet is tested to determine if it is an FEC packet, i.e.,tested to detect the presence of a bitmask. If "Yes", step S15 sets M tothe number of bits with value 1 in the bitmask. Step S17 sets K=SN, thesequence number base, where K is the current minimum sequence number ofthose media packets protected by FEC.

Step S19 increments a counter if bit I in the bit mask is set and bitK+I in the array is set, for I=1 to the size of the bitmask.

Step S21 checks to see if the counter setting is M. If "yes", step S23drops the FEC packet. If "no", step S25 checks to see if the countersetting is M-1. If "yes", step S27 sets n equal to the index of the bitin the mask which bit is set, but for which n the bit K+n in the arrayis not set. Step S29 recovers a packet n via f operator on FEC packettogether with packets in the array where bit is 1 and mask is 1.

The recovery procedure of step S29 is set forth in more detail below.

Further with respect to step S25, if the counter setting is not equal toM-1, step S31 checks whether the history is greater than maximum. If"yes", step S33 drops the FEC packet. If "no", step S35 sets K=thesequence number base, sets the FEC packet counter to 0, and sets I=0.

Processing then continues in this line. Step S37 checks to see if bit Iin the bitmask is set. If "yes", in step S39 the FEC packet is added tothe linked list of bit K+I in the array. If "no", the value i of I isincremented in step S41. Further, after step S39, step S40 incrementsthe FEC packet counter if K+I in the array is set and redirectsprocessing to step S41. After step S41, step S43 checks to see if thereare no more bits in the bitmask. If "yes" (There are no more bits in thebitmask), step S45 increments the history and proceeds to Stop, stepS47. If "no" (There are more bits in the bitmask), processing return tostep S37 to check whether bit I, now on a new value I, in the bitmask isset.

Consider now the other branch of the method at step S13. If the receivedpacket is not an FEC packet, then it must be a media packet. Step S48checks whether bit SN of the array is set. If "yes", Step S50 stopsprocessing. If "no", Step S49 sets n=SN, the sequence number of thepacket. Step S51 sets bit n in the array and stores the packet.

Step S52 increments the counters of all FEC packets linked to the arrayindex n. In response to step S52 and to the recovery step S29, step S53examines each FEC packet linked to array index n. If the value of thecounter is equal to the number of bits in the mask minus 1, step S53then uses the FEC packet to recover the packet n. If a packet isrecovered, step S55 decrements the history. The procedure then stops atstep S57.

The just-described checking procedure is a highly efficient method ofcounting, for each FEC packet, the number of array entries associatedwith that FEC packet that are also associated with a particular mediapacket.

According to the invention, in FIG. 1, the arrangement of the steps ofthe method cooperating with recovery Step S29 are the key to enablingthe receiver to correct errors in media packets even when the forwarderror-correcting code algorithm sent from the transmitter is changedwithout notice. Recovery step S29 requires two distinct operations. Thefirst step, which is executed by the flow chart as a whole, determineswhich media and FEC packets must be combined in order to recover amissing packet. The second step, which is step S29 itself, actuallyreconstructs the data. The second step must be performed as describedbelow. Different algorithms for the first step result in tradeoffsbetween complexity and the ability to recover missing packets. Thealgorithm of FIG. 1, which is the algorithm of the present invention,has proved to be highly advantageous.

Reconstructing the data (Step S29) uses the following steps, wherein Tis the list of FEC and media packets that should be combined to recovera media packet xi. In brief the packet xi is recovered by applying theinverse of f to the other received packets in T. The procedure is asfollows:

1. For the media packets in T, compute the binary array as described inthe previous section.

2. For the FEC packets in T, compute the binary array in the samefashion, except always set the CSRC list, extension and padding to null.

3. If the resulting binary arrays are not of equal length, pad them withzeroes to be the length of the longest binary array.

4. Apply the f inverse operator to the binary arrays, resulting in arecovery array.

5. Create a new packet with the standard 12-byte header and no payload.

6. Set the version of the new packet to 2.

7. Set the Padding Bit in the new packet to the first bit in therecovery array.

8. Set the Extension Bit in the new packet to the second bit in therecovery array.

9. Set the CC field to the next three bits in the recovery array.

10. Set the marker bit in the new packet to the next bit in the recoveryarray.

11. Set the payload type in the new packet to the next 7 bits in therecovery array.

12. Set the SN field in the new packet to xi.

13. Set the most significant 24 bits of the timestamp in the new packageto the most significant 24 bits of a nearby packet, preferably theprevious packet and set the least significant 8 bits of the timestamp tothe next 8 bits in the array. If the difference in timestamps betweenthe new packet and the previous, or a previous, packet is negative,there was a rollover. Increment the most significant 24 bits in thetimestamp of the new packet.

14. Determine what natural binary number corresponds to the next 16 bitsof the recovery array and append that many bytes of the recovery arrayto the new packet, to represent the CSRC list, extension, payload, andpadding.

15. Set the SSRC of the new packet to the SSRC of the media stream beingprotected by the new packet.

When all packets needed to recover a media packet are available, thepreceding procedure will completely recover both the header and payloadof the media packet with high probability. Any uncertainty relates tothe timestamp value when large timestamp increments are present.

EXAMPLE

Consider 2 media packets to be sent, x and y. We wish to protect them bysending one FEC packet which is derived from x and y. The f operator isimplemented using xor. The three packets are:

Media Packet x

Version: 2 (10)

Padding: 0 (0)

Extension: 0 (0)

Marker: 0 (0)

PTI: 11 (01011)

SN: 8 (1000)

TS: 3 (011)

SSRC: 2 (10)

The payload length is 10 bytes.

Media Packet y

Version: 2 (10)

Padding: 0 (0)

Extension: 0 (0)

Marker: 1 (1)

PTI: 18 (10010)

SN: 9 (1001)

TS: 5 (101)

SSRC: 2 (10)

The payload length is 11 bytes.

The FEC Packet (contains a xor b) is then:

Version: 2 (10)

Padding: 0 (0)

Extension: 0 (0)

Marker: 1 (1) (NOTE: 0 xor 1=1)

PTI: 191 (NOTE: Assume PTI 191 implies xor FEC)

SN: 1

S: 3

SSRC: 2 (10)

len. rec.: 1 (1) (NOTE: 10 xor 11=1010 xor 1011=0001)

PTI rec.: 24 (11001)

SN base: 8

TS rec.: 6 (110) (3 xor 5=6)

E: 0 (0)

mask: 3 (0000000000000011)

The payload length is 11 bytes.

One can consider an FEC packet as a redundant coding of the media.Because of this, the payload format for encoding of redundant audio datacan be used to carry the FEC data along with the media. The procedurefor this is simple. In some media packet, the payload type is set to thevalue for redundant encodings. The secondary coder is then set to be theFEC data. This means that the PTI of the secondary coder is set to thePTI value that indicates FEC. The block length of the secondary coder isset to the length of the FEC header and payload. The timestamp offset isset to the difference between the media timestamp and the timestamp fromthe FEC packet. The secondary coder payload includes the FEC header andFEC payload.

This procedure only works if an FEC packet is sent after at least one ofthe media packets it is associated with has been sent. Otherwise, thetimestamp offset would be negative, which is not allowed.

Using the redundant encodings payload format also implies that themarker bit cannot be recovered. An advantage of this approach is areduction in the overhead for sending FEC packets. A known example ofredundant encodings payload format can be found in Perkins et al., RTPPayload for Redundant Audio Data, Network Working Group, Request forComments (RFC) 2198, Category: Standards Track, atftp://ftp.isi.edu/in-notes/rfc2198.txt.

FIG. 2 shows an illustrative transmission system for implementing themethod of the invention. Transmitter 110 is separated from FEC-capablereceiver 120 by the occasionally lossy connectionless data network 100.In transmitter 110, the forward-error-correcting code generator 111 iscoupled through network interface 112 to the network 100. The datapackets to be transmitted are derived from camera 113 and microphone114. Their signals are sent through data compression circuit 115 so thatcompressed versions of the signals arrive at FEC generator 111. Bitmasksource 116 indicates to FEC generator 111 those media packets thatshould be covered by FEC. Selectable FEC code algorithm inserter 117inserts the operator's choice for forward error correction.

Selectable FEC code algorithm inserter 117 comprises either a hard-wiredlogic apparatus or a programmed central processing unit for insertingthe selected algorithm into a payload type header of each FEC packet.

Bitmask source 116 comprises either a hard-wired logic apparatus or aprogrammed central processing unit, in either case, illustratively undercontrol of the algorithm inserter 117, for associating aforward-error-correcting packet with a plurality of media packets.

In receiver 120, FEC decoder 121 receives the media packet streams andthe FEC packet streams from the network 100 through network interface122. The decoded media are decompressed in data decompressor 125 and aresent to monitor 123 and speaker 124, as appropriate.

FEC decoder 121 performs the method of FIG. 1 and is implementedaccordingly. It is noteworthy that transmitter 110 may differ from priortransmitters capable of transmitting FEC packets primarily only in theuse of bitmask source 116 and selectable FEC code algorithm inserter117.

If the packet streams are received at some receivers (not shown) thatare not FEC-capable, they can continue to operate with uncorrectederrors by simply ignoring FEC packets.

What is claimed is:
 1. A method for applying forward error correction tomedia packets in a transmission network, comprising the steps ofchoosingan error correcting code at a transmitter; generating a set of FECpackets, each FEC packet containing an offset bitmask associating theFEC packet with a media packet and containing a field sufficient toimpart the chosen error-correcting code to at least one FEC-capablereceiver; sending the packet stream, consisting of media packets and FECpackets, to the FEC-capable receiver; and decoding the packet stream atthe FEC-capable receiver, generating media packets as a result.
 2. Themethod according to claim 1, wherein the step of generating the set ofFEC packets includes the step of generating an FEC packet header,including the steps of:generating a sequence number base; generating theoffset bit mask with data of offsets from said sequence number baseindicating which media packets are associated with said FEC packet. 3.The method according to claim 2, wherein the step of generating thesequence number base comprises the steps of:computing the minimumsequence number of all media packets associated with said FEC packet;and setting said sequence number base to said minimum sequence number.4. The method according to claim 3, wherein the step of generating theoffset bitmask comprises the step of:setting bit I in said bitmask ifthe media packet with sequence number K+I is associated with said FECpacket, the value of K being equal to said sequence number base.
 5. Themethod according to claim 1, wherein the step of decoding comprises thesteps of:receiving a media packet; linking each FEC packet received withthose media packets associated with it; checking whether sufficientmedia packets have been received to allow an FEC packet to be used torecover a missing media packet; recovering said missing media packetshould such checking succeed.
 6. The method according to claim 5,wherein the step of linking comprises the steps of:constructing anarray; setting the Kth entry of said array to point to said FEC packetif said FEC is associated with media packet with sequence number K;further setting the Kth entry of said array to point to said mediapacket if said media packet is received, otherwise further setting saidarray to point to an empty object.
 7. The method according to claim 6,wherein the step of linking further comprises the steps of:associating anumber with said FEC packet, said number having a value equal to thenumber of media packets that have been received that are associated withsaid FEC packet; incrementing said number when another media packet isreceived that is associated with said FEC packet.
 8. The methodaccording to claim 6, wherein the step of checking further comprises thesteps of:associating array entry K with a received media packet, where Kis also the sequence number of the received media packet; traversing alist of FEC packets pointed to by array entry K; for each FEC packet,counting the number of array entries associated with said FEC packet,which array entries are also associated with a media packet; declaringsaid check to succeed if said counted number of array entries is equalto the number of array entries associated with said FEC packet, minusone.
 9. The method of claim 7, wherein the step of checking furthercomprises the steps of:associating array entry K with said media packet,where K is also the sequence number of said media packet as received;traversing a list of FEC packets pointed to by array entry K; for eachFEC packet, increasing said number associated with said FEC packet byone; declaring said check to succeed for any FEC packet if a count ofsaid list is equal to said number of array entries associated with saidFEC packet, minus one.
 10. The method of claim 5, wherein the step ofrecovering further comprises the step of performing the exclusive or ofthe content of those media packets associated with said FEC packet,which media packets have been received with content of said FEC packet.11. Apparatus for providing forward error correction in a transmissionnetwork for data packets transmitted therein, comprising:apparatus forproviding media data packets for transmission; a transmission interfacewith the network; a forward-error-correcting code generator forpreparing the media data packets and separable forward-error-correctingpackets for transmission through said transmission interface into saidnetwork, said forward-error-correcting code generator being capable ofoperating with a plurality of algorithms for forward error corrections;an algorithm inserter for inserting one of the plurality of algorithmsinto said forward-error-correcting code generator; a bitmask source forproviding to said forward-error-correcting code generator an offsetbitmask for insertion in the protocol header, the offset bitmaskassociating a forward-error-correction packet with at least one mediapacket; a reception interface with said network; and apparatus forproviding an error-corrected version of the media data packets receivedfrom the network through the reception interface, including a decodercapable of acquiring and using any of a plurality of algorithms forforward-error-correction received through the interface from thenetwork.
 12. Apparatus according to claim 11, wherein the algorithminserter comprises a first logic apparatus for inserting the onealgorithm into a payload type header of each FEC packet.
 13. Apparatusaccording to claim 12, wherein the bitmask source comprises a secondlogic apparatus controllable by the first logic apparatus forassociating the forward-error-correcting packet with the at least onemedia packet.